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Introduction 


I . 

The  objective  of  this  project  is  to  develop  an  expert  system  which  can  be  used 
to  make  a  short-range  weather  forecast  from  limited  input  data.  The  expert 
system  will  not  be  tied  to  any  particular  station.  This  will  be  done  by 
determining  and  utilizing  the  physical  relationships  between  the  synoptic 
weather  and  variables  that  affect  the  local  weather  such  as  terrain,  geography 
and  surface  type. 

This  interim  report  describes  our  opinions  and  progress  at  the  end  of  the 
first  year  of  this  three  year  contract.  During  this  period,  hardware  and 
software  options  have  been  reviewed  and  selected.  Knowledge  design  issues 
have  been  examined  and  some  tentative  class  and  object  networks  have  been 
defined  for  the  observation  database,  the  geographic  database  and  the  synoptic 
description.  A  major  decision  has  been  made  about  the  structuring  of  the 
expert  system  into  subdomain  knowledge  bases  that  can  be  called  upon  at  the 
appropriate  time  in  the  system's  operation.  The  basis  for  this  decision  and 
the  description  of  progress  on  various  software  pieces  of  the  system  are 
described  in  this  report.  Work  in  the  second  year  will  begin  to  tie  many  of 
these  pieces  together  as  we  move  to  construct  a  functional  expert  system. 


II.  Evaluation  of  Hardware  and  Software 

A.  Hardware 

The  hardware  choices  available  to  the  developer  and  user  of  a  complex  expert 
system  are  limited  to  mainframe  computers,  AI  workstations,  general-purpose 
workstations,  and  high-end  microcomputers.  Expert  system  development  software 
exists  for  all  classes  of  machines  with  cost  and  capabilities  increasing  with 
machine  power.  Mainframes  and  workstations  are  relatively  expensive,  and 
expert  systems  developed  on  these  machines  may  not  be  readily  ported  to  more 
common  and  affordable  machines.  Conversely,  the  wide  distribution  of 
relatively  inexpensive  IBM-compatible  microcomputers  based  on  80386  (and,  in 
growing  numbers,  80486)  processor  technology  makes  them  an  attractive  choice 
for  projects  of  scope  similar  to  that  undertaken  here. 

During  the  first  quarter  of  the  project  it  was  decided  to  use  an  80386-based 
microcomputer  (specifically,  a  Zenith  386)  as  the  initial  hardware 
environment.  Although  the  microcomputer  is  the  least  powerful  of  the  hardware 
options  mentioned  above,  it  was  judged  to  have  adequate  capabilities  for  the 
current  project.  The  choice  of  an  80386  was  made  with  the  knowledge  that 
suitable  expert  system  software  development  environments  were  available 
commercially.  The  80386  was  also  chosen  because  it  permits  effective  use  of 
graphics  with  adequate  resolution  (640  by  480  pixels,  16  colors)  for  the 
display  of  meteorological  data,  charts  and  other  products.  In  light  of  this 
decision,  a  4  Mb  add-on  memory  card  was  purchased  for  the  development  machine 
to  provide  sufficient  expansion  memory. 

B.  Software 

A  survey  of  available  expert  system  development  tools  was  made  to  determine 
which  would  be  most  suitable  for  the  needs  of  the  project.  Considerations  of 
cost,  capabilities,  and  ease  of  use  were  primary,  and  the  tool  had  to  be 
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available  for  80386  machines.  The  final  candidates  were  ES,  an  in-house 
expert  sySLem  shell,  and  NEXPERT,  a  product  of  Neuron  Data  Incorporated.  While 
ES  was  attractive  because  the  previous  Weather  Forecasting  Expert  System 
(WFES)  had  been  built  using  it  and  its  cost  was  negligible,  the  system's  long¬ 
term  support  was  uncertain.  NEXPERT  was  judged  the  better  candidate  because 
of  its  wide  range  of  features,  convenient  user  interface,  and  portability  of 
knowledge  bases  (KBs)  between  mainframes,  workstations  and  microcomputers. 
Support  for  NEXPERT  seemed  more  stable  given  its  growing  acceptance  in  the  AI 
marketplace . 

Another  NEXPERT  feature  that  was  found  to  be  especially  desirable  is  its 
ability  to  be  used  in  an  embedded  form,  allowing  the  developer  to  invoke  KBs 
from  high-level  languages.  This  facilitates  the  separation  of  domain 
knowledge  from  program  control  structure,  the  latter  being  difficult,  or  at 
least  cumbersome,  to  express  in  KB  form.  Past  experience  has  shown  that  the 
considerable  control  structure  in  expert  systems  can,  when  coded  into  KBs, 
degrade  the  clarity  of  KB  meaning.  Using  the  NEXPERT  KBs  and  library 
functions  in  embedded  form  allows  the  developer  to  use  library  functions 
developed  by  other  vendors  as  well.  This  is  particularly  relevant,  as  the 
current  project  requires  the  use  of  graphics  libraries  and  a  large  number  of 
meteorological  computation  functions. 

The  NEXPERT  expert  system  development  environment  and  NEXPERT  run-time  library 
for  IBM  PCs  were  purchased  during  the  third  quarter. 

III.  Knowledge  Design 

A.  Knowledge  Bases 

Experience  suggests  that  small  and  single-purpose  KBs  (typically  having  less 
than  100  rules)  are  easier  to  develop,  revise,  and  test.  Smaller  KBs  have 
fewer  rules  that  must  be  made  functional,  generally  require  fewer  inputs,  and 
are  conceptually  simpler  to  understand  and  deal  with.  Such  KBs  are  also  more 
efficient  for  being  enujedded  within  a  larger  program  where  they  can  be  loaded 
when  needed  and  unloaded  when  their  processing  is  completed.  This  modularity 
can  help  produce  faster,  more  efficient  programs  and  can  reduce  development 
time . 

The  ongoing  design  of  the  WFES  makes  use  of  smaller  KBs.  Although  still 
undergoing  development,  the  knowledge  structure  of  the  WFES  will  be  placed  in 
a  hierarchy.  The  highest,  or  global  KB  will  carry  all  the  classes,  objects 
and  constants  that  are  present  throughout  the  forecasting  session.  Secondary 
KBs  will  be  loaded  when  specific  tasks  are  undertaken  (such  as  loading  surface 
data,  performing  an  analysis,  etc.)  and  will  include  quantities  with  scope 
limited  to  the  task.  Small  KBs  that  perform  more  specialized  functions,  such 
as  determining  the  airmass,  will  be  loaded  as  needed. 

The  analysis  process  exemplifies  the  approach  of  using  ordered  KBs  (Figure  1) . 
The  Global  KB,  loaded  at  program  initiation,  maintains  the  classes  and  objects 
needed  to  describe  observations,  climate  and  geography  data.  The  loading  of 
the  Analysis  KB  defines  additional  classes  and  objects  whose  scopes  are 
limited  to  the  analysis  process.  These  classes  and  objects  will  be  visible  to 
all  subsequent  KBs  until  the  Analysis  KB  is  unloaded.  An  Airmass  KB  is  loaded 
to  determine  the  airmasses  present,  stores  the  new  information  in  objects 
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belonging  to  the  analysis  KB,  and  is  unloaded.  Similarly,  other  KBs  are 
loaded,  executed,  and  unloaded  until  the  analysis  is  complete.  At  the 
conclusion  of  the  analysis  phase  of  the  program,  only  the  analysis  KB  remains 
to  hold  the  analysis  itself. 

B.  Classes  and  Objects 

Class  and  object  networks  are  useful  structures  for  the  defining  and  sharing 
of  properties  and  values  between  both  physical  and  abstract  entities.  A  class 
can  define  the  properties  that  are  distinct  to  a  concept,  and  an  object  can 
represent  a  realization  of  the  concept.  In  this  study,  the  main  class 
networks  contain  information  about  weather  entity  relationships,  observation 
and  forecast  properties,  the  spatial  nature  of  weather  entities,  geographic 
features  and  climate  types. 

An  early  version  of  the  weather  entity  and  geometry  networks  (Figure  2) 
demonstrates  the  simple  hierarchy  involved  in  defining  weather  features.  For 
example.  Figure  3  illustrates  that  an  cold  front  can  be  a  member  of  the  class 
COLD_FRONT,  which  is  a  subclass  of  the  class  FRONT.  FRONT,  in  turn,  is  a 
subclass  of  the  classes  ENTITY  and  M0VING_LINE.  M0VING_LINE  is  a  subclass  of 
LINE,  and  LINE  is  a  subclass  of  GEOMETRIC_ELEMENT .  The  actual  cold  front  is 
expressed  as  an  object  that  has  properties  inherited  from  its  ancestor 
classes.  The  object  inherits  properties  specific  to  all  fronts  (such  as 
vertical  slope,  associated  airmasses,  intensity)  from  FRONT,  properties  unique 
to  cold  fronts  (e.g.,  the  likelihood  of  a  steeper  slope)  from  COLD_FRONT. 

Also  inherited  are  the  properties  and  attributes  of  line-like  features  from 
LINE  and  the  properties  needed  to  describe  the  motion  of  a  line  from 
MOVING_LINE . 

IV.  Implementation 

A.  Control  Shell 

Experience  has  shown  that  expert  systems  often  require  a  considerable  control 
structure  to  internally  regulate  their  activities.  The  control  structure  can 
be  characterized  as  procedural  instructions  that  are  virtually  devoid  of  what 
is  classically  referred  to  as  "knowledge”.  Because  they  contain  little 
knowledge,  they  are  not  as  well  expressed  within  a  KB  as  they  might  be  in  a 
more  procedural  language  such  as  C  or  Pascal.  While  the  separation  of 
procedural  information  from  knowledge  can  never  be  complete,  it  would  seem 
advantageous  to  use  a  high  level  language  such  as  C  to  regulate  KB  activity, 
thereby  keeping  the  latter  "cleaner". 

The  use  of  a  C  "shell"  program  that  contains  the  procedural  information  also 
has  advantages  for  expert  system  development.  KBs  designed  and  built  using 
the  NEXPERT  development  environment  can  be  tested  as  stand-alone  entities. 
However,  their  integration  with  other  KBs  becomes  more  difficult  as  the  number 
and  size  of  the  system  KBs  grow.  Since  the  KBs  will  ultimately  be  integrated 
within  a  C  shell  that  will  supply  and  manage  many  of  the  KB  inputs  and 
outputs,  it  is  logical  to  construct  the  shell  in  the  early  stage  of  KB 
development.  The  shell  can  then  accept  each  new  KB  as  it  comes  "on  line"  and 
test  it  in  the  environment  for  which  it  was  intended.  Because  the  shell 
manages  the  complex  climate,  geography  and  observation  databases,  these 
databases  can  be  used  to  test  the  KBs  in  an  efficient  manner.  Without  the 
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shell,  only  simple  data  can  be  used  in  testing  because  of  the  memory  and  speed 
limitations  of  the  development  environment. 

For  these  reasons  the  implementation  of  a  C  shell  for  the  WFES  has  been 
started.  The  shell  presently  performs  the  functions  of  graphical  user 
interface,  surface  data  editor,  and  platform  for  KB  integration.  The  user 
interface  is  devised  to  guide  the  user  through  the  following  tasks:  selection 
of  database  information;  loading  of  data;  production,  inspection,  and 
modification  of  analyses;  and  production,  inspection,  and  modification  of 
forecasts.  The  interface  "locks  out"  options  or  tasks  that  are  inappropriate 
and  indicates  when  analyses  or  forecasts  are  no  longer  current  (i.e.,  new 
observations  have  been  loaded  or  analyses  have  been  modified) . 

B.  Geographic  Database 

Geographic  data  will  be  used  by  the  expert  system  to  determine  the 
representativeness  of  surface  winds,  the  location  of  nearby  bodies  of  water 
that  may  modify  local  conditions,  the  presence  of  large-scale  topographic 
features,  etc.  In  addition,  the  data  will  supply  a  graphic  map  of  the 
forecast  area,  incorporating  topography,  seas,  lakes  and  rivers,  political 
boundaries  and  landmarks. 

A  geographic  database  program  has  been  created  that  interrogates  simple  map 
and  geography  datasets  and  creates  data  files  that  are  tailored  for  use  by  the 
WFES  at  a  designated  location.  These  products  include:  grids  of  elevation 
above  sea  level,  land  use,  water  coverage,  and  urbanization;  map  elements  that 
define  land  areas,  lakes,  rivers,  islands,  and  political  boundaries;  and  an 
chart  of  the  forecast  area  that  displays  all  of  the  above-mentioned  data  on  an 
azimuthal  equidistant  projection.  At  the  present  time  the  resolution  of  the 
geographic  data  is  about  15  to  20  miles. 

Currently  under  development  is  a  class/object  description  of  geographic 
features  that  can  affect  meteorological  conditions.  An  example  is  the  class 
LAKE  (see  Figure  2),  which  could  have  the  properties  of  surface  temperature, 
frozen/liquid  status  and  depth.  LAKE  would  also  have  the  properties  of  area, 
shape,  orientation,  defining  points  and  location  relative  to  the  forecast  site 
that  it  inherited  from  the  superclasses  STATIC_REGION  and  REGION. 

The  full  geographic  description  should  be  completed  by  second  quarter  of  year 
two . 

C.  Observation  and  Forecast  Displays 

The  most  acceptable  and  efficient  way  to  convey  meteorological  information  to 
the  forecaster  has  been  through  graphic  presentations.  In  recognition  of  this 
fact,  a  number  of  graphic  interfaces  will  be  created  for  the  WFES  so  that  its 
actions  and  conclusions  can  be  understood  by  the  user.  Two  interfaces  that 
have  been  created  during  the  first  year  of  the  contract  and  are  now  functional 
are  designed  to  depict  the  12-hour  forecast  and  observations  of  the  past  five 
days . 

The  forecast  display  (Figure  4)  is  a  mixed  text-graphics  presentation.  Text 
fields  provide  forecast  values  of  temperature,  pressure,  and  so  on,  while 
winds  are  shown  using  wind  barbs  and  cloud  types  are  depicted  by  their 
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standard  symbols.  Temperature  and  pressure  changes  are  emphasized  by  up  or 
down  arrows,  and  visibility  is  given  both  in  text  and  visual  form. 

The  long  period  display  of  past  observations  and  forecast  is  more  purely 
graphic,  taking  the  form  of  colored  charts  of  temperature,  pressure,  wind  and 
clouds.  This  presentation  provides  rapid  understanding  of  past  meteorological 
events  and  conditions  by  plainly  showing  important  surface  features  such  as 
wind  gusts,  wind  shifts,  and  changes  in  cloud  amount  and  height. 

V.  Plans  for  Year  2 

A.  System  Design 

The  use  of  a  shell  for  the  KBs  places  the  burden  of  planning  on  the 
organization  and  ordering  of  KBs.  The  shell  itself  will  need  to  interact  with 
the  KBs,  maintain  the  databases,  and  perform  other  graphic  services.  These 
are  largely  procedural  tasks,  however,  and  can  be  dealt  with  using  relatively 
routine  solutions.  The  more  difficult  division  of  knowledge  into  small  KBs, 
the  ordering  of  KBs  and  the  design  of  KB  hierarchy  all  will  demand  greater 
care.  Finalizing  the  system  design  will  be  the  first  priority  of  Year  2. 

Concurrent  with  (and  a  part  of)  system  design  will  be  the  finalization  of  the 
class  and  object  networks  needed  to  describe  the  physical  entities  within  the 
system.  Network  design  is  inherently  a  part  of  system  design  when  the  system 
is  made  up  of  many  overlapping  and  nested  KBs,  each  needing  a  specific  range 
of  classes  and  objects  in  order  to  function. 

B.  Knowledge  Bases 

When  the  system  design  is  finalized  the  encoding  of  forecaster  knowledge  can 
begin.  This  will  start  with  the  building  of  KBs  to  interrogate  single 
observations  for  airmass  types,  then  progress  through  other  KBs  to  defining 
the  current  synoptic  state  (or  model) .  The  following  development  will  add  the 
ability  to  deal  with  time  series  of  data,  thereby  completing  what  is  called 
the  Analysis  KB  in  Figure  2.  At  this  point  the  first  round  of  evaluation  and 
validation  will  be  performed  and  the  KBs  modified  according  to  the  results. 

C.  Integration 

A  number  of  capabilities  will  be  integrated  with  tb^  she)!  that  are  now 
functional  as  stand-alone  programs.  These  include  graphics  routines  for 
observation  and  simple  forecast  display,  geographic  database  viewers  and  the 
upper  air  sounding  analysis  package  developed  prior  to  this  contract.  New 
graphics  routines  to  be  coded  and  integrated  include  the  upper  air  observation 
editor  and  a  sophisticated  viewer  of  the  analysis  and  forecast  models. 

Newly-created  KBs  will  be  integrated  with  the  shell  as  they  become  functional, 
so  that  during  the  evaluation  and  validation  phase  of  Year  2  the  entire  system 
(as  exists  at  that  time)  will  be  exercised  rather  than  a  collection  of  pieces. 
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ENTITY 

- AIRMASS 

- ARCTIC_AIRMASS 

- CA 

- mA 

- POLAR_AIRMASS 

- CP 

- mP 

- TROPICAL_AIRMASS 

- cT 

- mT 

- CYCLONE 

- FRONT 

- COLD_FRONT 

- WARM_FRONT 

- STATrONARY_FRONT 

- OCCLUDED_FRONT 

- TROUGH 

- RIDGE 

- PRESSURE_SYSTEM 

- HIGH 

- LOW 

- TROPICAL_SYSTEM 

- HURRICANE 

- TROP I CAL_S  TORM 

- TROPICAL  DEPRESSION 


GEOMETRIC_ELEMENT 

- POINT 

- MOVING_POINT 

- PRESSURE 

- TROPICAL 

- STATIC_POINT 

I - LANDMARK 

- LINE 

- MOVING_LINE 

- FRONT 

- TROUGH 

- RIDGE 

- STATIC_LINE 

- RIVER 

- ROAD 

- MOUNTAIN 

- REGION 

- MOVING_REGION 

I - AIRMASS 

- STATIC_REGION 

- LAKE 

- OCEAN 

- ISLAND 

- MOUNTAIN 

- ^VALLEY 

- BASIN 

- CITY 


FIGURE  2,  Class  Relationships  in  the  WFES 
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SYSTEM 


RIDGE 


RANGE 
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FIGURE  3 
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GEOMETRIC_ELEMENT 
t ^ - I^NE 


MOVING_LINE 
ENTITY 

- ^RONT 


COLD  FRONT 


* 


Relationship  of  COLD  FRONT  Class  to  ENTITY  And  GEOMETRIC  ELEMENT 
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Forecast 


•  roc 


